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SHELFS:  A Proactive  Method  for  Managing  Safety  Issues 


A.  Rizzo,  & L.  Save 

Multimedia  Communication  Laboratory 
University  of  Siena 
Via  dci  Termini  6 
53100  Siena,  Italy 

Summary.  Safety  knowledge  is  an  important  asset  for  managing  safety  critical  organisations.  In  the  paper  we 
claim  that  reactive  methods  are  not  the  more  adequate  approach  to  capture,  represent  and  reuse  safety 
knowledge.  The  organisational  model  of  accidents  and  the  organisational  learning  processes  ask  for  a different 
approach  in  analysing  and  documenting  safety  issues.  We  present  a proactive  approach  having  a holistic  view 
of  the  productive  system,  where  all  the  system  components  and  their  interactions  are  analysed.  Examples 
drawn  by  an  experimentation  of  the  method  are  used  to  illustrate  it. 

1.  INTRODUCTION 

Knowledge  is  considered  the  most  relevant  asset  of  modem  organisations.  Most  of  this  knowledge  belongs  to 
people  and  it  is  embodied  in  the  human  practices  and  interactions  among  people  and  artefacts,  and  it  could 
become  organisational  knowledge  only  if  properly  captured,  managed  and  reused.  Modern  organisations  strive 
to  capture  this  knowledge  since  they  consider  it  an  important  factor  for  improving  the  quality  of  their 
processes.  Yet  many  safety  critical  organisations  concerning  safety  issue  prefer  a reactive  approach  to  learn 
from  experience:  the  one  based  on  the  analysis  of  reports  from  accidents,  incidents  and  near  misses.  Following 
the  direction  pointed  out  by  Reason  (1991)  we  claim  that  reactive  methods  are  not  the  more  adequate 
approach  to  capture,  represent  and  reuse  safety  knowledge.  We  consider  reactive  approaches  as  too  slow  and 
inadequate  for  supporting  an  efficient  experience  feedback.  Here  it  is  presented  a proactive  method  tailored 
for  introducing  human  factors  in  a safety  critical  company,  which  is  based  on  a distributed  knowledge  view  of 
the  working  processes.  This  method  stresses  the  positive  face  of  safety  and  is  oriented  toward  a positive  return 
of  experience  from  the  human  practices. 

Proactive  approaches  do  not  just  consider  events  with  negative  outcomes  but  also  the  vital  signs  of  safety, 
such  as  the  best  practices  and  the  solutions  identified  by  managers  and  operators  to  overcome  organisational 
and  technical  problems,  and  promote  the  development  of  such  vital  signs.  Even  though  this  approach  was 
suggested  by  Reason  early  in  the  ’90,  there  are  not  yet  many  tools  and  methods  for  introducing  the  approach 
in  large  organisations  dealing  with  complex  processes  with  safety  critical  implication.  In  addition,  there  is  a 
lack  of  methods  tailored  for  organisations  that  are  planning  human  factors  programmes  but  that  do  not  have  a 
long  tradition  in  human  factors.  In  most  of  the  cases  these  organisations  would  like  to  introduce  human  factors 
progressively,  having  an  immediate  evidence  of  the  results  this  introduction  is  producing.  On  the  contrary, 
well  established  and  sound  methods  like  HazOp  (Kletz,  1993),  OARU  (Kjellen,  & Larrson,  1981)  or  MORT 
(Johnson,  1980)  require  large  initial  investments,  and  can  be  very  time-consuming.  In  addition  these  methods 
are  not  straight  oriented  to  capture  best-practices  and  solutions.  Effective  organisational  learning  processes 
require  a return  of  experience  based  on  an  everyday  practice  involving  all  the  stakeholders  involved  in  a 
process. 

To  try  to  face  these  issues  we  present  a progressive  method  oriented  toward  short-term  experience  feedback  as 
well  as  mid  and  long  term  actions.  The  method  and  related  tools  aim:  1)  at  analysing  and  documenting  safety 
issues  for  identifying  proactive  safety  actions;  2)  at  promoting  organisational  learning  as  an  everyday  practice. 

In  the  following  we  outline  a well-know  systemic  model  used  to  consider  the  human  role  in  a process  and  his 
relationships  with  the  other  process  components.  We  elaborated  the  model  on  the  base  of  the  cultural- 
historical  approach  (Cole,  1996)  and  their  recent  version  known  as  distributed  cognition  theory  (Norman, 
1993)  and  used  the  SHEL  model  as  a conceptual  framework  for  developing  the  method  and  the  tools, 
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described  below.  This  method  have  been  experimented  in  a program  for  introducing  human  factors  principles 
in  the  Italian  National  Railways  organisation  (FS). 

2.  THE  SHEL  MODEL 

Edwards  (1972)  proposed  a conceptual  model,  named  SHEL,  to  describe  the  behaviour  of  interactive  system 
with  special  regard  to  human  factors  issues.  SHEL  is  the  acronym  for  Software,  Hardware,  Environment,  and 
Liveware: 

Software  represents  any  component  such  as  the  computational  code,  the  policies,  norms,  rules,  procedures, 
practices  and  any  other  formal  or  informal  rules  that  define  the  way  in  which  the  different  components  of  the 
system  interact  among  them  and  with  the  external  environment. 

Hardware  represents  any  physical  and  non-human  component  of  the  system  as  equipment,  vehicles,  tools, 
manuals,  signs. 

Liveware  represents  any  human  components  in  their  relational  and  communicational  aspects. 

Environment  represents  the  socio-political  and  economic  environment  in  which  the  different  components  of  a 
process  interact  as  shown  in  Fig.  3. 

The  SHEL  model  concentrates  on  the  interfaces  among  people  and  all  system  components  including  other 
Liveware  resources.  SHEL  offers  a system  view  where  humans  cannot  be  considered  isolated  from  other 
system  components.  This  view  is  consistent  with  a long  lasting  and  empirically  well  grounded  theoiy  of 
human  cognition:  the  cultural-historical  theory,  of  Vygotsky,  Luria  and  Leontev  (for  a review  see  Cole,  1996). 
Recently,  several  authors  have  elaborated  along  the  main  ideas  of  Vygotsky’s  approach  (e.  g.  Engestrom, 
1987;  Hutchins,  1995;  Norman,  1993).  The  recent  elaboration  of  cultural-historical  theory  (e.g.  Distributed 
Cognition,  Activity  Theory)  and  the  SHEL  model  share  the  assumption  that  any  productive  process  is  always 
defined  by  a specific  combination  of  Hardware,  Software  and  Liveware  resources  which  mediate  the 
execution  of  human  activity.  The  relationship  between  the  SHEL  model  and  the  Vygotsky’s  unit  of  analysis  of 
human  activity  by  can  be  summarized  in  Figure  1 


Figure  1 : The  SHEL  model  at  the  light  of  Vygotsky’s  unit  of  analysis  of  human  activity 

3.  THE  SHELLS  METHOD  AND  TOOLS 

Using  the  SHEL  model  as  a possible  simplified  expression  of  the  Cultural-historycal  framework  we  developed 
a method  and  relative  tools,  named  SHELFS,  for  identifying  and  managing  the  potential  sources  of 
breakdowns  in  the  interaction  among  human  and  the  other  system  components.  SHELFS  was  developed 
within  the  programme  for  introducing  human  factors  techniques  in  the  Italian  Railways  Company  (FS).  Next 
sub-session  will  describe  briefly  this  context  of  application. 
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3.1  The  context  of  application 

The  railways  transportation  system  in  Italy  is  managed  by  a single  organisation  named  “Ferrovie  dello  Stato” 
(FS).  Different  Departments  of  FS  take  care  of  the  railways  network,  infrastructures,  personnel  and  rolling 
stock.  The  “ASA  Rete”  Department  is  in  charge  of  the  rail  tracks  management  and  maintenance  and  these 
activities  have  a direct  impact  on  the  safety  of  the  whole  rail  traffic.  Operators  involved  in  rail  tracks 
management  usually  perform  routinely  work,  in  isolated  operative  contexts.  In  ease  of  emergency  they  have  to 
provide  quick  answers,  with  few  opportunities  to  verily  their  decisions  with  colleagues  or  with  their 
responsible.  Operators  of  the  maintenance  section  work  in  teams,  usually  in  hostile  environments  and  under 
stressing  conditions  such  as  the  presence  of  time  pressure.  Both  activities  are  characterised  by  the  presence  of 
heterogeneous  systems  interacting  with  the  operators,  and  by  the  use  of  rapidly  evolving  operative 
methodologies  and  technologies.  The  “ASA  Rete”  Department  identified  the  need  to  support  the  operators 
involved  in  these  activities,  in  particular  for  the  aspects  of  their  interactions  with  the  other  operators  and  with 
the  technological  and  procedural  structures  they  are  using.  A safety  analysis  of  the  organisation  evidenced 
also  the  need  to  collect  and  preserve  the  safety  knowledge  of  the  operators  in  presence  of  problems  of 
turnover  and  downsizing  of  the  company. 

As  a partial  answer  to  these  needs  “ASA  Rete”  launched  the  “Line  Tutor”  program.  Line  tutors  are  specially 
selected  operators  that  behave  as  tutors  for  their  colleagues.  They  will  also  analyse  the  every  day  operators' 
activity,  under  normal  and  abnormal  conditions,  with  the  additional  aim  of  extracting,  rationalising  and 
reporting  the  safety  knowledge  embedded  in  their  behaviour.  Line  Tutors  have  been  selected  between 
operators  with  a well-established  experience  of  the  typical  operator  roles;  selection  was  based  on  their 
knowledge  and  ability  for  this  new  position.  The  SHELFS  method  was  developed  for  this  Line  Tutor  role, 
which  was  supposed  to  have  only  a basic  knowledge  of  human  factors  engineering. 

3.2  Method  and  tools 

The  method  supports  the  activity  of  an  operator  whose  role  is  to  identify  critical  issues  and  to  develop  and 
propose  adequate  solutions.  The  method  supports  also  the  organised  collection,  diffusion  and  re-use  of  the 
corporate  knowledge  existing  at  the  level  of  single  or  small  group  of  workers.  In  particular,  corporate 
knowledge  is  used  during  the  identification  of  possible  solutions  for  the  critical  issues  that  could  originate 
more  serious  problems.  The  operator  must  have  a good  knowledge  of  the  working  processes  and  of  the 
working  environment  he  is  going  to  analyse.  Approaches  concerning  “best  practice”,  as  for  example  the 
CARMAN  approach  of  Embry  and  Richardson  (1998)  or  the  LINE/LOS  checklist  of  Connelly  (1997)  shares 
with  SHELFS  the  aim  of  documenting  safety  issues  for  identifying  proactive  safety  actions.  However  they  arc 
mainly  focused  on  one  of  the  SHEL  component,  for  example  the  CARMAN  approach  is  a powerful  methods 
to  cope  with  gaps  between  procedures  and  practices,  and  the  LINE/LOS  checklist  is  carefully  tailored  to  face 
Crew  communication  performance.  On  the  contrary  SHELFS  try  to  capture  the  web  of  interaction  among  all 
the  components.  Indeed,  some  of  the  techniques  used  in  best-practices  approaches  could  be  easily  integrated 
into  SHELFS,  taking  for  granted  that  the  distributed  cognition  philosophy  should  drive  their  application. 

The  SHELFS  method  is  articulated  in  three  main  phases: 

• definition  of  the  process; 

• identification  of  the  critical  issues; 

• identification  of  possible  solutions. 

In  the  first  phase  (definition  of  the  process)  the  Line  Tutor  identifies  and  models  the  process  he  is  going  to 
analyse.  This  is  done  with  the  direct  involvement  of  the  personnel  representing  each  role  that  is  needed  to 
carry  out  the  process.  The  process  is  defined  with  the  first  tool  of  the  SHELFS  method:  the  Matrix  Workflow 
(see  fig  2).  The  Matrix  Workflow'  allows  representing  a process  according  to  its  basic  activities,  the  personnel 
involved,  the  communication  flow,  the  regulations  and  procedures  and  the  hardware  involved. 
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Figure  2:  The  representation  of  situated  process  trough  the  workflow  matrix 


The  interactions  between  humans  (Liveware-Liveware)  are  the  element  that  identifies  the  different  steps  in 
which  the  process  is  subdivided:  every  time  the  actors  change  a step  is  identified,  when  the  actors  remain  the 
same  also  the  step  remains  the  same.  However,  it  is  always  possible  to  get  into  the  details  of  a given 
Liveware-Liveware  step  by  analyzing  the  interaction  between  humans  and  the  other  components  (Liveware- 
Software  and  Liveware-Hardware).  For  example  people  interactions  can  be  analysed  with  the  conversational 
model,  or  the  NASA/FAA/LOS  checklist  (Connelly.  1997);  Liveware-Software  interactions  by  checking 
compliance  to  procedures;  Liveware-Hardware  with  cognitive  walkthrough  (Riz.zo,  et  al,  1997). 

The  output  of  this  phase  is  a representation  of  the  process  under  analysis  where  the  focus  is  on  workflow  and 
critical  activities  of  the  process  itself.  Using  this  representation  the  Line  Tutor  can  start  the  second  phase 
(identification  of  the  critical  issues)  investigating  the  real  breakdowns  experienced  by  the  workers  while 
performing  the  process  and  the  related  causes.  This  is  done  using  a simplified  resource  analysis  method  in 
colloquies  and  interviews  with  the  workers  involved  in  the  process.  The  resource  analysis  method  is  a 
hierarchical  taxonomy  that  relates  the  critical  issues  to  the  components  identified  in  the  SHEL  model. 

The  details  of  the  taxonomy  are  not  very  important  for  the  proposed  approach,  only  the  8 main  classes  of 
breakdown  play  an  important  role. 

HI  Are  the  tools  dependable  and  effective  in  playing  the  role  for  which  they  have  been  introduced  in  the 
process? 

H2  The  supporting  material  (e.g.  manuals,  workbook,  signals,  etc)  supports  the  activity  when  needed? 

H3  The  physical  environment  (climate,  layout,  furniture,  etc.)  allows  a comfortable  execution  of  the 
activity? 

51  The  knowledge  needed  to  carry  out  the  activity  is  covered  exhaustively  by  regulations,  procedures, 
instructions,  available  in  the  company? 

52  Practice  actually  adopted  to  carry  out  the  activity  is  consistent  with  regulations  and  procedures? 

53  The  specific  knowledge  needed  to  carry  out  the  activity  is  adequate  and  sufficient? 

LI  The  flow  of  communication  is  timing  and  adequate  to  support  the  activity? 

L2  The  activity  distribution,  both  for  the  single  operator  in  time  and  between  the  operators  in  time  and 
space,  is  instrumental  to  cany  out  the  activity? 

Indeed,  many  of  the  sub-classes  included  in  the  taxonomy  are  similar  to  that  proposed  by  other  tools  as  the 
General  Failure  Types  proposed  by  Reason,  or  the  Human  Error  Analytic  Taxonomy  (Bagnara  et  al.,  1991),  or 
the  Project  Evaluation  Tree  put  forward  by  Stephenson  (1997).  However  there  are  three  important  differences 
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with  these  related  works.  The  first  is  that  human  psychophysics  conditions  (e.g.  attention,  decision  making, 
reasoning;  motivation)  are  not  considered  as  critical  issues  since  they  are  strongly  influenced  by  the 
interactions  with  all  the  others  system  components  (Software,  Hardware,  Liveware)  and  cannot  be  faced 
individually.  The  second  is  that  using  SHELFS  the  Line  Tutor  refines  the  same  definition  and  the  analysis  of 
the  possible  critical  issues  interactively  and  iteratively,  with  the  people  involved  in  the  process  along  the  three 
phases  of  SHELFS.  The  third  is  that  the  three  main  classes  of  the  taxonomy  are  not  mutually  exclusive,  on  the 
contrary  one  critical  issue  can  concern  one  class  as  well  as  all  the  three  main  classes.  It  is  important  to  stress 
this  point  since  it  is  at  the  core  of  the  proposed  method.  As  in  the  first  phase  the  aim  was  to  map  the  main 
classes  of  resources  involved  in  a process,  in  this  second  phase  the  aim  is  to  assess,  according  to  the 
experience,  how  well  the  resources  interact  among  them. 

During  this  second  phase  the  Line  Tutor  needs  to  go  only  through  the  8 main  potential  critical  issues.  Three  of 
the  critical  issues  concern  the  Hardware,  three  the  Software  and  two  the  Liveware.  The  8 main  classes 
represent  different  ways  of  mining  the  interaction  among  components.  The  distinction  is  not  only 
phenomenological  but  also  grounded  in  the  adopted  theoretical  approach.  Software  resources  can  be  prone  to 
wrong  interaction  since  they  do  not  cover  all  the  interaction  among  components  (SI),  leaving  space  for  the 
development  of  idiosyncratic  practices.  It  is  important  to  note  that  in  complex  system,  Software  resources  (e.g. 
Rules,  procedures,  computational  code,  etc.)  cannot  anticipate  all  the  possible  state  of  components  interaction. 
Notwithstanding  this,  it  is  possible  to  be  conscious  of  this  limit  and  do  not  pretend  that  it  does  not  exist. 
Software  can  be  also  not  instrumental  at  good  interaction  when  do  not  promote  the  development  of  working 
practices  consistent  with  procedures  and  regulations  (S2),  or  when  it  do  not  assure  that  the  relevant  knowledge 
that  operator  should  manage  is  properly  practised  in  tuition  and  training  (S3).  Hardware  can  embody 
knowledge  that  can  conflict  with  Software  or  Liveware  components  since  degraded,  or  not  anymore  adequate 
to  face  the  evolution  of  knowledge  occurred  in  the  Software  and  Liveware  components,  or  even  since  it  was 
not  designed  at  all  for  the  interaction  (HI).  Hardware  can  be  also  prone  to  faulty  interaction  when  the 
embodiment  of  knowledge  is  carried  out  with  artifacts,  like  writing  or  sign  devoted  to  represent  other  artifacts 
and  modes  of  action  (e.g.  manuals,  display,  signals),  w'hich  are  not  tailored  to  the  working  condition  or  since 
the  knowledge  representation  is  not  relevant  or  effective  for  the  interaction  (H2).  Finally,  Hardware  can  mine 
the  interaction  when  the  physical  environment  instead  to  be  instrumental  to  the  designed  interactions  hamper 
them  (H3).  The  Liveware  resource  can  be  fond  to  mis-interaction  when  the  communication  flow,  for  w'hat 
concerns  both  content  and  form,  is  fragile  and/or  not  well  designed  (LI)  or  when  the  work  distribution  among 
operators  and/or  in  the  single  operators  is  not  instrumental  to  the  activity  (L2). 

Notwithstanding  the  possible  lack  of  attention  the  organization  can  have  for  these  sources  of  potential 
breakdowns  the  people  involved  in  the  productive  system  will  strive  to  accommodate  them  locally,  by 
modifying  the  relationship  between  the  system  components.  Sometime  this  accommodation  reveals  and 
creates  space  for  opportunities  that  should  be  properly  managed  by  the  organization  to  capture  the  knowledge 
they  have  embedded.  The  investigation  based  on  SHELFS  tends  to  identify  this  knowledge  and  to  use  it  in  the 
identification  of  solutions  for  the  critical  issues  (phase  3 of  the  method). 

The  aim  of  the  proposed  taxonomy  is  to  support  the  Line  Tutor  in  catching  an  inadequate  distribution  of 
resources  for  one  or  more  steps  of  a process.  To  this  aim  at  least  one  representative  for  each  of  the  working 
positions  involved  in  the  process  under  analysis,  is  interviewed.  This  allows  the  Line  Tutor  to  have  a complete 
idea  of  all  the  potential  breakdowns  associated  with  that  process. 

For  example,  taking  into  consideration  the  above  reported  process  “Departure  from  Track  5 of  Train  BD-813- 
74  from  X to  Y”,  in  Figure  3 we  can  observe  the  summary  of  the  process  and  the  related  map  of  critical  issues 
according  to  the  different  roles  involved.  The  critical  issues  represent  a grouping  of  potential  breakdowns,  that 
put  together  the  problems  associated  w'ith  a subset  of  the  whole  process  and  a pool  of  roles.  The  critical  issue 
arc  defined  according  to  the  techniques  of  “one  sentence  problem  statement”  (Newman  and  Lamming,  1995) 
and  in  agreement  with  the  operators,  which  also  rate  the  priority  of  the  critical  issues. 
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INTERVIEW  PLAN  AND  EMERGING  CRITICAL  ISSUES 
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Figure  3:  A summary  of  the  critical  issues  associated  with  a process. 

The  MAC,  CT,  DM,  VER,  VEIC  and  MAN  tags  represent  different  roles  involved  in  the  process. 

The  numeral  associated  with  the  tag  represent  the  number  of  people  interviewed. 

The  cluster  of  breakdowns  are  represented  by  mean  of  grey  patches. 

At  the  end  of  this  second  phase  the  Line  Tutor  has  a process  description  with  the  associated  critical  issues,  and 
a description  of  the  way  in  which  they  are  locally  managed  by  re-distributing  the  Hardware,  Software  and 
Human  resources. 

This  constitutes  the  input  for  the  last  phase  of  the  method  (identification  of  possible  solutions),  where  the  Line 
Tutor  organises  a meeting  with  the  representatives  of  all  the  human  roles  necessary  to  cany  out  the  process 
under  analysis.  The  meeting  play  an  important  role  in  the  SHELFS  approach,  it  is  derived  by  the  participatory 
meeting  proposed  by  the  Scandinavian  school  (cf.  Greenbaun  and  Kyng,  1991).  During  this  meeting  all  the 
critical  issues  are  analysed,  discussed  and  possible  solutions  are  proposed  by  the  same  workers  involved  in  the 
processes  under  analysis,  with  the  mediating  role  of  the  Line  Tutor.  The  meeting  (one  or  more  if  needed)  is 
organised  in  four  sessions: 

• declaration  and  awareness  of  critical  issues 

• critique  and  analysis  of  the  critical  issues 

• envisioning  solutions 

• implementing  solutions 

In  the  declaration  and  awareness  session  the  critical  issues  collected  by  the  Line  Tutor  are  presented  to  the 
participants  with  the  support  of  the  "one  sentence  problem  statement".  That  is,  the  Line  Tutor  summarises  in 
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one  sentence  a given  critical  issue  reporting  in  the  sentence:  the  activity;  the  way  in  which  this  activity  is 
hampered;  the  roles  involved;  the  possible  regulations  and/or  hardware  involved. 

For  example,  the  fist  critical  issues  of  the  above  reported  process  was  “ The  Train  driver  and  the  Train 
Manager  could  not  respect/check  the  maximun  speed  allowed  and  reported  on  the  Train  Form  but  not 
consistent  with  the  maximun  speed  reported  on  the  M40  form” 

The  aim  of  this  session  is  the  mutual  awareness  of  the  critical  issues  associated  to  a given  process  by  all  the 
roles  involved.  The  Output  is  a list  of  sentences  that  express  the  process  critical  issues  restated  and  shared  by 
all  the  participants  of  the  meeting,  (see  figure  4) 


Critical  Issue 

Aritiritia 

i metre! 

Stifcf  of  the  Critical 
issue  in  »rda~ 

PROBLEM  IN  ONE  SENTENCE 

1 

7-8-9-10 

11-13 

A 

Tit  Train,  driver  and  tit  Tram  Manager  could  not 
respect/check  tit  maximun  speed  allowed  and  reported  on 
tlie  Train  Form  but  not  cons  is  tent  with  tlie  maximun  speed 
reported  on  tlie  M40  form 

B 

Tit  Train  driver  and  tit  Tram  Manager  could  be 
constrained  to  read  the  travel  forms  when  lit  Train  is 
already  travelling  by  receiving  die  documentation  not  in 
time  orwhile  they  where  performing  other  tasks 

2 

34-5-6 

A 

Tit  comrm  ideation  between  die  Train  driver  and  dt 
Venficator,  not  adequately  supported  b y the  available  tods 
and  by  the  specific  training  for  dt  sole,  could  produce 
misundeistandnig  that  delay  dt  departure  of  do  not  allow 
to  resoect  the  procedures. 

B 

Tit  ccmniinication  flew  among  VER,  DM,  CT,  MAC 
concerning  the  brake  test  is  not  always  clear  arid  efficient, 
with  the  chance  that  tlie  Train  could  departure  without  that 
the  MAC  will  become  conscious  of  possible  variations  on 
die  train  characters;  tics . 

Figure  4:  Example  of  “one  sentence  problem  statement”  related  to  the  first  two  critical  issues  of  the 
“Departure  from  Track  5 of  Train  BD-813-74  from  X to  Y”  process 


In  the  Critique  and  analysis  session  every  critical  issues  is  illustrated  by  specific  events  and  stories  reported  by 
the  roles  involved.  The  level  of  analysis  is  established  according  to  actions  already  experimented  on  the  field 
and  according  to  the  interactions  among  the  roles.  It  is  important  that  the  level  of  analysis  of  the  critical  issue 
will  allow  the  communication  between  roles  even  though  there  can  still  be  substantial  differences  in  the  way 
the  problem  is  perceived.  If  different  levels  of  analysis  are  proposed  by  different  roles,  the  Line  Tutor  will 
accept  all  of  them  and  propose  to  address  the  levels  one  by  one.  The  sentence  representing  the  critical  issue  is 
located  at  the  centre  of  a graph.  The  details  of  the  criticality,  defined  according  to  the  SHELFS  taxonomy  and 
the  roles  interested  in  the  critical  issue  are  also  represented  in  the  graph,  in  direct  connection  with  the 
sentence.  The  aim  of  this  session  is  to  define  the  details  of  the  critical  issue  and  the  level  where  it  seems 
manageable.  The  output  is  provided  by  the  criticality  graphs,  which  explode  a critical  issues  in  relation  to  the 
roles  involved  and  the  possible  factors  foreseen  by  SHELFS. 

For  example,  for  the  critical  issue  1 A we  had  the  following  SI  and  S2  breakdowns: 

MAC  1 - The  M40  form  might  disturb  me.  There  are  useless  prescriptions  and  other  stuff  already  reported  on 
the  Train  Form 
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MAC  2 - The  M40  is  misleading.  If  I am  tired  it  can  confuse  me 

MAC  2 -The  regulations  to  which  we  should  refer  (REG.243  e PGOS)  are  waiped.  In  critical  situation  they 
can  even  create  big  problems. 

Which  could  lead  to  the  best  of  the  case  to  a violation  of  the  regulation,  and  in  the  worse  of  the  case  to  the 
overcoming  of  the  maximum  speed  that  a train  could  safely  sustain,  according  to  the  class  of  cars,  the 
percentage  of  braking  mass,  etc. 

Along  this  session  it  was  found  that  the  critical  issue  related  to  the  Train  Form  and  to  the  M40  form  was  due 
to  the  overlapping  of  the  regulations  governing  two  different  type  of  travel  documents:  The  Train  Form  itself, 
recently  introduced,  and  the  Time  Pamphlet,  which  represent  the  traditional  document  supporting  the  train 
travel.  The  Time  Pamphlet  has  always  been  associated  to  the  M40  as  a complementary  form  where  to  point 
out  to  the  Driver  possible  additional  prescription.  The  same  M40  is  today  associated  with  the  Train  Form, 
which  include  a more  appropriate  description  of  the  Train  data.  This  could  makes  superfluous  some  of  the 
data  reported  in  the  M40  (or  viceversa).  But  why  one  should  remove  one  of  the  two  prescriptions  of  speed 
and  which  one? 

During  the  Envisioning  solution  session  everyone  is  free  to  submit  solutions,  the  only  constraint  is  the  request 
to  specify  them  in  relationship  to  the  Software,  Hardware  and  Liveware  components.  This  is  a real 
brainstorming  session,  so  long  speech  and  killing  sentences  like  “this  is  completely  unrealistic”  are  inhibited 
by  the  Line  Tutor.  The  aim  of  this  session  is  to  go  away  from  established  position  and  from  defensive  and 
conservative  attitude,  so  to  give  room  to  alternative  and  possible  solutions  before  to  prepare  the  operative 
proposals. 

In  the  envisioning  session  it  become  clear  But  the  real  critical  issue  laid  in  two  different  criteria  for  assessing 
and  reporting  the  maximum  speed,  and  their  relationship  with  the  new  philosophy  for  train  traffic 
management  introduced  w'ith  the  new  organisation  of  the  FS  holding.  Here  we  will  not  go  into  the  detail  of  the 
two  regulations,  which  will  need  a deep  understanding  of  the  work  organisation  and  its  history.  But  we  would 
highlight  how  the  meeting  allowed  to  goes  beyond  the  surface  of  the  problem  (apparent  redundancy  of 
information).  This  was  fundamental  to  provide  the  right  rationale  for  the  suggested  modifications.  Indeed, 
until  the  critique  and  analysis  session  the  two  different  divisions  were  blaming  each  other  for  the 
inconvenient:  the  Train  drivers  blamed  the  Train  Traffic  Manager  for  providing  incorrect  prescriptions, 
instead  the  Train  Traffic  Manager  blamed  the  Train  Driver  to  not  knowing  the  rule  governing  the  use  of  M40. 
During  the  meeting  both  roles  devised  a shared  solution:  To  eliminate  the  prescription  to  report  the  maximum 
speed  of  the  train  on  the  M40  if  this  is  higher  than  the  one  initially  scheduled  for  that  Train.  With  this  solution 
the  Train  Driver  are  not  induced  in  confusion,  and  the  Train  Traffic  Manager  can  highlight  relevant 
information  in  a simpler  way.  It  is  important  to  stress  that  this  apparently  simple  solution  has  been  accepted 
only  through  the  shared  understanding  of  the  two  different  criteria  for  assessing  and  reporting  the  maximum 
speed  and  their  relationship  to  the  new  modalities  of  train  traffic  management. 

In  the  Implementing  solutions  session  the  critical  issues  are  organised  by  priority,  everyone  is  free  to  submit 
his  own  order  and  the  consensus  on  priorities  in  not  required.  The  ranks  average  decides  the  order  of 
discussion.  The  proposals  should  be  feasible  in  the  short/medium  term  since  it  is  of  paramount  importance  to 
test  them  on  the  field.  Moreover,  the  proposal  should  specify  the  possible  modalities  of  implementation  and 
specify  the  new  distribution  of  knowledge  among  the  Software,  Hardware  and  Liveware  components,  even  if 
the  critical  issues  is  apparently  well  confined  within  one  component. 

The  activity  of  the  Line  Tutor  ends  with  the  implementation  of  short  term  actions  and  their  monitoring,  and 
the  collection  of  medium  teim  actions  together  with  the  results  of  the  short  teim  actions  so  to  present  a deeper 
analysis  for  potential  improvement  of  the  whole  process. 
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4.  CONCLUSION 

In  experimenting  the  proposed  proactive  method  we  found  on  average  7 critical  issues  for  each  process 
examined,  on  average  5 of  them  where  analysed  and  discussed  in  the  meeting  and  for  4 of  them  a shared 
solution  was  found.  In  many  cases  the  critical  issues  where  known  to  the  Line  Tutors,  but  in  several  other 
cases  the  critical  issues  emerged  with  the  SHELFS  method  were  unknown  to  the  same  people  involved  in  the 
process.  For  many  of  them  a solution  was  proposed  that  could  be  also  extended  to  other  processes  that  share 
similar  distribution  of  resources. 
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